🔴 Docker Hub secrets not declared or passed for publish-webapp.yml, causing login failure

The new Docker Hub login step uses ${{ secrets.DOCKERHUB_USERNAME }} and ${{ secrets.DOCKERHUB_TOKEN }}, but these secrets are neither declared in the workflow_call.secrets section of publish-webapp.yml nor passed by the caller in publish.yml:72-74 (which only passes SENTRY_AUTH_TOKEN). In GitHub Actions, when a caller explicitly lists secrets (rather than using secrets: inherit), only declared and passed secrets are available to the called workflow. Both secrets will resolve to empty strings, causing the docker/login-action step to fail. Since this step lacks continue-on-error: true, it will abort the entire publish job, preventing the image build and push.

Two changes are needed to fix the Docker Hub login for publish-webapp.yml:

1. In .github/workflows/publish-webapp.yml, add DOCKERHUB_USERNAME and DOCKERHUB_TOKEN to the workflow_call.secrets section (around line 17-19), similar to how publish-worker.yml declares them at its lines 11-15.

2. In .github/workflows/publish.yml, update the publish-webapp job (around line 73-74) to also pass these secrets, similar to how publish-worker passes them at lines 84-86. Add:
   secrets:
     SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
     DOCKERHUB_USERNAME: ${{ secrets.DOCKERHUB_USERNAME }}
     DOCKERHUB_TOKEN: ${{ secrets.DOCKERHUB_TOKEN }}

Additionally, consider adding a conditional guard (if: ${{ secrets.DOCKERHUB_USERNAME != '' }}) or continue-on-error: true on the Docker Hub login step to avoid hard failures when the secrets are not configured (e.g. in forks). See publish-worker.yml:63 for the existing pattern.

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 Docker Hub secrets not declared or passed for publish-worker-v4.yml, causing login failure via workflow_call

Same issue as in publish-webapp.yml: the new Docker Hub login step uses ${{ secrets.DOCKERHUB_USERNAME }} and ${{ secrets.DOCKERHUB_TOKEN }}, but these are not declared in the workflow_call.secrets section of publish-worker-v4.yml, and the caller at publish.yml:90-98 passes no secrets at all. When invoked via workflow_call, both secrets will be empty and the login step will fail, aborting the build job. (When triggered directly via push tags, repository secrets are available, so only the workflow_call path is broken.)

Two changes are needed:

1. In .github/workflows/publish-worker-v4.yml, add a secrets section under workflow_call (after line 10) declaring DOCKERHUB_USERNAME and DOCKERHUB_TOKEN as optional secrets, matching the pattern in publish-worker.yml:11-15.

2. In .github/workflows/publish.yml, update the publish-worker-v4 job (around line 96) to pass these secrets:
   secrets:
     DOCKERHUB_USERNAME: ${{ secrets.DOCKERHUB_USERNAME }}
     DOCKERHUB_TOKEN: ${{ secrets.DOCKERHUB_TOKEN }}

Also consider adding a conditional guard on the Docker Hub login step (like publish-worker.yml:63 does with if: ${{ env.DOCKERHUB_USERNAME }}) to gracefully skip when secrets are unavailable.

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 Docker Hub login uses unpinned mutable tag @v3 instead of commit SHA, inconsistent with all other action references

Both new Docker Hub login steps use docker/login-action@v3 while every other docker/login-action reference in the repository (8 occurrences across 7 workflow files) is pinned to a specific commit SHA: docker/login-action@4907a6ddec9925e35a0a9e82d7399ccc52663121 # v4.1.0. Using a mutable tag is a supply-chain security risk (the tag can be moved to point at malicious code) and is inconsistent with the established repository convention. Additionally, @v3 is an older major version than the v4.1.0 used everywhere else.

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 Docker Hub login in publish-worker-v4 uses unpinned mutable tag @v3 instead of commit SHA

Same issue as in publish-webapp.yml: the new Docker Hub login step uses docker/login-action@v3 instead of the pinned commit SHA docker/login-action@4907a6ddec9925e35a0a9e82d7399ccc52663121 # v4.1.0 used by all other workflow files in the repository. This is both a supply-chain security risk and a convention violation.

Was this helpful? React with 👍 or 👎 to provide feedback.